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A Guide to Controls 
And Window Types 



Corporate developers designing 
a graphical user interface 
(GUI) often face a double- 
edge sword: A well-designed 
user interface leads to reduced 
end user training and support, 
while a poorly designed inter- 
face mires users in a mind- 
numbing plethora of haphaz- 
ard controls and dialog boxes. Since 
there are a number of different types of 
controls and windows, the successful 
GUI designer needs to have a firm un- 
derstanding of when it's appropriate to 
use one control over another. Just as the 
plenitude of cheap fonts has led to ran- 
som-note typography, the number and 
quality of today's custom-development 
controls often lead developers to ran- 
som-note control usage. In this column, 
you'll learn more about the basics of 
windows and controls that serve as the 
foundation for a well-designed user in- 
terface. 

OPENING WINDOWS As the name of the 
operating environment would lead you to 

believe, windows are the fundamental ob- 
jects through which most user interaction 
takes place. Like the wise man who built 
his house upon the rock, your Windows 
application needs a solid foundation upon 
which to add functionality. 

As you develop Windows applications 
for other users within your company, 
your goal always should be to maintain as 
much consistency with other Windows 
applications as possible. Why force a user 
to learn some new or inconsistent action 
when you could make a design decision 
to use a standard control or behavior 
that's already known to the user? Let's 
start with a review of the kinds of win- 
dows that you can use in your application 



and when to use each one. 

Window types include primary (also 
called application or main) windows, mul- 
tiple document interface (MDI) windows, 
MDI child windows (also referred to as 
document windows), and dialog boxes. 
Applications routinely create and use 
other windows that include dialog boxes, 
MDI child windows, and non-MDI child 
windows. 

CHOOSINfi THE BIfiHT WINDOW If users 
will be working with a variaUe amount of 

data but just one type of data, use a stan- 
dard main application data to 

window, as the Write 
and Notepad acces- 
sories do. If your pro- 
gram needs to pro- 
vide access to 
multiple sets of data 
or to multiple views of 
one data set, make 
the main window an 
MDI window and dis- 
play the data sets in 
MDI child windows. 



In tins column, you'll learn 
more about the basics 
ofiuindoivs and controls 

that serve as the 
foundation far a weU- 
destgned user interface. 



mize buttons. To make matters a bit 
more complicated, the main window can 
be just a dialog box, in which case the 
user won't be able to size the window 
frame. If your main application window 
is a dialog box, include a control-box 
menu and a minimize button but not a 
maximize button. 

• MDI windows. An MDI window is ca- 
pable of creating and managing multiple 
MDI child windows. Just as Windows 
manages a desktop full of main program 
windows, an MDI application manages a 
set of MDI child windows, also called doc- 
ument windows. Document windows can 
be tiled or cascaded within the MDI win- 
dow, and they can be reduced to icons, 
again within the MDI window. The child 
windows always stay completely inside 
the main program window. 

In general, if your application calls for 
complex data entry or the ability to view 
multiple data elements, use a main MDI 
window and create MDI child windows 
as necessary. Before you begin designing 
your application, spend some time think- 
ing about the way you plan to present 

the user. If 
there's any chance 
that the user would 
need to open another 
window while halfway 
through the work 
process, choose the 
MDI window option. 
That way, your appli- 
cation can open up an 
MDI child window, 
let the user interact 
with the data, and 



Program Manager is then return to the 



the most ubiquitous 
example of an MDI program. Finally, if 
your program's interaction with the user 
is simple and straightforward, consider 
using a simple dialog box as the main ap- 
plication window. The Calculator and 
Giaracter Map accessories are two ex- 
amples of programs whose main window 
is a dialog box. Figure 1 shows three of 
the four types of windows that are avail- 
able to you: 

• Application windows. The main appli- 
cation window usually contains a resiz- 
able frame and a title bar. In addition, 
application windows should have a con- 
trol-menu box, and minimize and maxi- 



original work. 
• MDI child windows. The third kind of 
window is the MDI child window. MDI 
child windows share almost all the charac- 
teristics of an application window. They 
can be resized, minimized, and maximized 
but always within the main MDI window. 
When an MDI child window is maxi- 
mized, its title is appended to the title of 
the main MDI window (for example, 
"Program Manager - [Main]"). 

The ability to open more than one 
MDI child window lets your application 
display more than one data set or more 
than one kind of data set. Users can ei- 
ther work on many data sets at once or 
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Figure 1: Three of the four available window types are shown 
in this figare. The main application Is an MDi window that 
eoirtaftts MM ciilld wimtaws. The dialog box Is also consldersd 

a window. 



easily compare the contents of similar 

forms. For example, consider a purchase- 
order application where, after working 
through the first half of the PO, the user 
might have to enter information about a 
customer. If the user tries to edit a cus- 
tomer record that doesn't exist, he 
shouldn't have to exit from the order 
screen and lose all of the data already en- 
tered just to enter a new customer. Why 
not just open an MDI child window to 
enter the new customer information, save 
the data, and then close the window be- 
fore continuing? 

Because the term document might be 
confusing, it's acceptable to call these 
windows by more appropriate names 
that refer to the context of the data. For 
example, Figure 2 shows Program Man- 
ager with two open document windows 
called Main and CommWorks. Al- 
though the Program Manager refers to 
these as group windows, they are still 
just MDI document windows. On the 
other hand, if the application is Mi- 
crosoft Word for Windows or WordPer- 
fect, it's correct to refer to these win- 
dows as documents. 

As you design your applications, jjive 
some thought to how many MDI win- 
dows the user can open at one time. For 
example, if you're developing an appli- 
cation for entering purchase orders, you 
might permit the user to work on multi- 
ple purchase orders in multiple docu- 
ment windows at the same time. If you 
also let him have a customer window 
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open for each purchase order, 
chances are good he'll be con- 
fused by all the windows 
splashed across the screen. I've 
found that providing multiple 
instances of the primary ob- 
jects and single instances of the 
peripheral objects works well. 
• Dialog boxes. Dialog boxes 
provide a two-way interaction 
between the application and 
the user. On one hand, applica- 
tions use dialog boxes to gel 
more information from the 
user before a command can be 
completed. The controls that 
you use in a dialog box collect 
information and pass that in- 
formation back to the applica- 
— — tion. On the other hand, dialog 
boxes also present data to the user via 
message boxes and the initial values of 
controls displayed in (he dialog box. Di- 
alog boxes can have a minimize button 
(and perhaps they should if the dialog 
box is the application) and even a menu 
bar. 

Let's take a moment to bone up on 
the three types of Windows dialog boxes: 

modeless, modal, and system modal. 
What you want your application to ac- 
complish will dictate the kind of dialog 
box you implement. Choose modeless di- 
alog boxes for on-going tasks or to pre- 
sent information that will be helpful to 
keep on the screen for a while. For ex- 
ample, many applications implement a 
Find dialog box that stays visi- 
ble so that the user can select 
Find Next several times before 
closing the dialog box. Figure 3 
shows Word for Windows 6.0's 
spell-checker, a good example 
of a modeless dialog box. Tool- 
bars are often implemented as 
modeless dialogs. Users can 
continue to work in the appli- 
cation even when a modeless 
dialog box is active. 

Use modal dialog boxes ^— 
when the application needs a specific 
piece of information before it can contin- 
ue. Once the user supplies the necessary 
information or cancels the operation, the 
dialog box closes and the application con- 
tinues. A good example of a modal dialog 
box is the FilelOpen dialog box fH'esent in 



most applications. In this case, the appli- 
cation can't work on the file until the user 
either tells it which file to open or cancels 
the process of opening a file. Once the 
user selects the filename or cancels the 
operation, there is no reason to keep the 
dialog box around, because it will only 
clutter the screen. When a modal dialog 
box is active, the user cannot do anything 
else in the application until that dialog has 
been closed. Use this kind of dialog box 
sparingly. 

System modal dialog boxes are rare 
and should be used only when the user's 
response is required for some problem re- 
lating to the whole system. Chances are 
good you'll never use these, because when 
this type of modal dialog is active, the user 
can't do anything in any application until 
the dialog is closed. An example of this 
kind of dialog box is a fatal hardware 
error or an impending systemwide memo- 
ry shortage. 

Another use of the dialog box is to pre- 
sent informational, warning, or critical 
messages to users. Let's spend a couple of 
paragraphs on the message box, since 
your users will see a lot of them during 
their time spent with Windows! 

Some message boxes simply convey 
information or issue a warning — "File 
not found," for example — and an OK 
button to clear the message after the user 
has read it. For these cases, you might 
display just a button that dismisses the 
dialog box when the user is done reading 
the message. Other dialog boxes want a 
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figun 2: The Windows Program Manager Is an MDI application 
that UMS MDI child (docnment) windows for program groups. 
In this example, two MDI child windows— titled Main and 

CommWorks— are visible. 



clarification from the user before pro- 
ceeding: "It's Tuesday. Fax standing 
order to the pizza shop?" accompanied 
by Yes and No buttons. Finally, some 
message boxes present a cpicry with the 
option to answer Yes, No, or Cancel: 
"Overwrite existing file?" 
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Message boxes contain one of four 
standard icons. A stop sign indicates a 
critical error, a circled exclamation mark 
represents a warning message, and a cir- 
cled letter i means an informational mes- 
sage. Some message boxes display a cir- 
cled question mark when asking a 
question of the user, but since the ques- 
tion mark is often associated with Help, 
its meaning in the context of a message 
box is ambiguous and shouldn't be used. 

DON'T BE A CONTROL FREAK Controls 
are those interface elements (command 
buttons, scroll bars, list boxes, edit boxes, 
and so on) that handle interaction with 
the user. In most cases, controls serve 
both to get information from the user 
and to display information about the cur- 
rent application status. For instance, 
scroll bars in a word processor not only 
let the user move around within a file but 
also display the user's current position 
within that file. Radio buttons (which are 
described below) both show the current 
selection and let the user change that se- 
lection. 

Right out of the box, Windows pro- 
vides a number of controls that you can 
use when designing an application. Al- 
though you might be tempted to use a 
wide variety of custom controls (including 
the numerous Visual Basic .VBX con- 



Figure 4 shows a dialog box contain- 
ing some of the common Windows con- 
trols that you can use in your applica- 
tions. Let's spend a few moments 

reviewing each of the controls and when 
it's appropriate to use them. 
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figure 3: The Microsoft Word for Windows speii-ciioeinr Is a 
good sxamplo of a fflodeiess dialog liox. You can mora around 
the document and edit text even witli the dialog box active. 



trols), you should carefully consider using 

existing controls before using a control 
that might be unfamiliar to users. To a 
new Visual Basic or PowerBuilder devel- 
oper, it's really easy to lose control and try 
out each of the custom controls found in 
those environments. 



figun it Tills dialog box contains most of tiio common 
Wlndsws interfaco eontrols.. Each iaiboiod item is de- 
scribed In more detail in the text 



• Command buttons. A command but- 
ton is a rectangular button that contains 
a label describing a command or action 
that the application will carry out when 
the button is pressed. The button labels 
are usually text, but many applications 
also use bitmapped images on a com- 
mand button. Users can either click on 
the command button or hold down the 
Alt key while pressing the un- 
derlined character that ap- 
pears on the button's caption. 
These keyboard shortcuts are 
an essential part of good inter- 
face design. 

Use care assigning labels 
for keyboard shortcuts, and 
ensure that no two controls in 
a dialog box are mapped to the 
same keyboard shortcut. 
You're heading for a train 
wreck if you define the key- 
board shortcut of O for both 
the Orders command button 
and the OK command button. 
Wherever possible, use the 
— ^ first letter of the label as the 
keyboard shortcut, but if that creates a 
conflict with another label, choose an- 
other letter that makes it easy for the 
user to remember the command. 

Place the standard command but- 
tons — usually OK and Cancel — in one 



cation's dialog boxes and the buttons for 
other features in a different consistent 
location (perhaps stacked vertically 
above the OK and Cancel buttons). Re- 
member to provide keyboard shortcuts 
for all menu items and controls (except 
the OK and Cancel buttons, 
which should be mapped to the 
Enter and Esc keys, respective- 
ly). Every Windows program 
should be completely operable 
using only the keyboard, unless 
its function depends solely on 
another type of input device, 
such as a mouse or a puck. 
• Radio buttons. Use radio 
buttons (sometimes called op- 
tion buttons) as a way to pre- 
sent a single choice from a lim- 
ited set of mutually exclusive 
choices. The control gets its 
name from the old car radio 
buttons of the fifties and six- 
ties: Push one button and the others pop 
out. Radio buttons are represented 
graphically as a circle that is filled when 
the user chooses that option. Use radio 
buttons when the number of choices is 
limited to usually no more than four or 
five choices. If you need to present more 
than five choices, use a standard or 
drop-down list box. 

• Check boxes. Choose check boxes if 
you want to present a list of choices to 
the user where they can make more than 
one selection from the list. Check boxes 
are represented by squares that display 
an X when the option is selected and are 
blank when the option is deselected. 
(Some applications have check boxes 
that use a check mark instead of an X.) 
As you can see in Figure 4, you can as- 
sign keyboard shortcuts to both check 
boxes and radio buttons — a feature your 
laptop-equipped mobile executives with 
limited mouse real estate will certainly 
appreciate. 

• List boxes. A list box normally dis- 
plays a column of choices. If there are 
too many choices to display at once, a 
scroll bar to the right of the list lets the 

user scroll through the choices. By de- 
fault, list boxes let the user select only 
one item, although you can design a list 

box to permit multiple-item selection. In 
addition, another flavor of list box. 



consistent location for all of your appli- called a combo box, lets you present 
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provides labels for the controls, but it's 
up to you to label other controls. Keep 
static text strings short and align data- 
entry fields to make navigation easier. 
Be consistent when labeling controls by 
developing a list of reserved words for 
lections when the fea- controls in order to 



multiple items to the user but permits 
him to type in his own response if the 
correct one isn't on the list. 

Because it's easy to add or subtract 
data elements from the list, consider 
using list boxes for single or multiple se- 



tures or data that you 

present to the user is 
dynamic. Drop-down 
lists and combo boxes 
are an attractive op- 
tion when screen real 
estate is limited or 
when the user won't 
need to access the list 
of choices very often. 
,• Text boxes. Text 
boxes are controls 
into which the user 
types information. 



If you choose the right 
window and mntrol 
elements for your 
Wtndoivs-based applica- 
iwm,you'U be rewarded 
wilh more productivity 
and fewer headaches. 



prevent multiple 

meanings of the same 
word. For example, I 
have seen the OK 
button used in non- 
standard ways, such 
as to close one win- 
dow and invoke an- 
other. This behavior 
is both inconsistent 
and confusing. 
• Groop boxes. Final- 
ly, use group boxes to 
group together related 



Within the text box controls and to pro- 



control, the user may 
navigate text by pressing the Left or Right 
Arrow key and select text by holding 
down the Shift key while pressing the Left 
or Right Arrow key. Text boxes also sup- 
port navigation and selection with the 
mouse. Text boxes can be of the single- 
line or multiline variety. The Windows 
Notepad is just one multiline text box 
with a menu bar. The dialog box in Figure 
1 contains four single-line text boxes. 
• Static text fields. Be sure to label your 
controls with static text fields. In some 
cases — that is. for buttons, check boxes, 
and group boxes — the operating system 



vide visual consistency 
throughout your dialog boxes. Although 
group boxes are technically considered 
controls, the user can't manipulate them 
with the mouse or the keyboard. The 
most common use of a group box is to en- 
close groups of radio buttons or check 
boxes. 

HONEY, I HID THE CONTROL Consider 
whether you want to disable unavailable 
menu items and controls (leaving them 
visible but grayed out) or hide them. In 
general, graying a control is much safer. 
Users are often confused when menu 
items or controls keep appearing and 



Deciding on Controls for Dialog Boxes 


H you wantto 


Usee 


But no mom (tan- 


Trigger an action 


Command button 


Sk par dialog hax 


Choose among a few mutually 
exclusive options 


RedlB button 


Sb( per group 


Choose one or more of a few 
nonexclusive options 


Checit box 


Ten per group 


Get arbitrary text data from the user 


Text box 




Choose among mutually exclusive options 


Ustbox 


50 itMns, displayed 8-10 at a time 


Choose one or more nonexclusive options 


Mul^ile seleetien lot box 


50 items, displayed 8-10 at a time 


Choose among mutually exduswe options 
while using a minimum of space 


Drop-down list box 


20 items, displayed 1 at a time 


Choose among mutually exclusive options 
or enter a new value 


Combo box 


20 items, displayed 1 at a time 


Group rnla'P'- ' 

buttons d'.: 


Label controls that don't have their own 
labels (list boxes, for example) 


Sutic text field 





disappearing. The only reason to hide 
GUI components is if the user will never 

have access to specific menu items or 
controls. For example, you might choose 
to hide certain controls in a window or 
dialog box based on the user's security 
level at log-on. Another reason to leave 
disabled controls in place is if you've 
provided context-sensitive help. That 
way, users can tab to the disabled con- 
trol and press the Fl to get context-sen- 
sitive help in order to figure out why 
they can't access the control. 

CONCLUSION Figure 5 summarizes the 
issues you should consider when using 
controls in dialog boxes. While Windows 
controls can often accommodate a large 
number of choices, it's not a good idea to 
explore that limit with your users. Note, 
for instance, the suggested maximum 
number of choices for a list box. I've 
found that users get frustrated after hit- 
ting PgDn or scrolling through 50 or more 
items. With a longer list, consider provid- 
ing a method for reducing the list to create 
a subset from which the user can choose. 
A simple data-entry field where the user 
can enter a partial string to search on 
would work well, for example. 

If you find that you're spending a lot of 
time with user-interface issues, you owe it 
to yourself to look into The Windows Inter- 
face: An Application Design Guide (Micro- 
soft Press, ISBN: 1-55615-439-9). This in- 
terface bible is the definitive compilation of 
Windows UI arcana, from accelerator keys 
to z-order, with discussions on both the ap- 
pearance and the behavior of Windows in- 
terface elements. This book is essential 
when setting corporate standards. 

Choosing the ri^t window and control 
elements for your Windows-based appli- 
cation forms a strong foundation for the 
rest of the application. If you make the 
right choices and don t try to get too far 
out onto the bleeding edge of interface 
technology, you will be rewarded with 
more productivity and fewer support 
headaches. Making the wrong choice, on 
the other hand, is the stuff GUI night- 
mares are made of. □ 



Figure 5: This table summarizes tlie availabla standard interface 
ed limits to tlic numlier of centrois tiiat you siioaid nu in a lincle 
tlie diiriog box becomes dlfncalt to understand. 



elements and siiows recommond- 
dlalog box. Too many controls and 
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